In the following discussion specific reference is made to Internet protocol version 6 (IPv6) and multi-field classification (MFC). It is to be understood, however, that the concepts of the present invention are not limited to IPv6 and MFC but the described implementation is intended as exemplary only.
IPv6 represents an evolutionary development to overcome some limitations in IPv4. In particular, the routing and addressing limitations of IPv4 place a real limit on the address configurations available based on a 32 bit field limit. IPv6 has increased the address field to 128 bits. This supports more levels of addressing hierarchy as well as a much greater number of addressable nodes. Additionally, some IPv4 header fields have been dropped to reduce the processing cost of packet handling and to limit the bandwidth cost of the IPv6 header. A new capability has been added to IPv6 which enables labeling of packets belonging to particular traffic flows for which the sender requests special handling based on quality of service or real time handling. Additionally, the mechanism to add optional internet-layer information to a packet has changed. In IPv4, this is achieved through the option field which is a part of the IPv4 header. The Internet Header Length (IHL) field in the IPv4 header indicates the length of these extra fields and the basic header. However, due to the length of the IHL field, only a limited number of options could be added to a packet. In IPv6, internet-layer information is added using extension headers. These headers are added to an IPv6 packet between the IPv6 header and the upper-layer header. Each extension header contains a field identifying the type of the next header, and instead of using a field similar to the IHL of IPv4, IPv6 specifies the length of each extension header in the extension headers themselves. This allows an unlimited number of extension headers to be added to an IPv6 packet.
FIG. 1 shows the IPv6 header format including the flow label field.
Regular packet processing typically requires fields from upper-layer headers. Multi-Field Classification (MFC), one of many examples of processing such data, usually classifies packets based on the 5-tuple <Source IP, Destination IP, Source Port, Destination Port, Protocol>. When options or extension headers are used, it can become difficult and costly to reach the upper-layer header in order to retrieve the data necessary for packet processing.
For IPv4, processing packets with options is simple as the aforementioned IHL field can be used to skip over the entire IPv4 header, including any appended options, to reach the upper-layer header.
For IPv6, reaching the upper-layer header is significantly more difficult for packets containing extension headers as the IPv6 header does not have a field like the IHL in IPv4 that can be used to immediately reach the upper-layer header. One prior art solution is to traverse the extension headers serially. Since the length of each extension header is stored in the extension header itself, this appears to be the most obvious solution. Thus, IPv6 packet processing becomes costly if a number of extension header need to be traversed before the upper-layer header can be reached and regular packet processing performed. This cost seems even more unnecessary since the presence of IPv6 extension headers does not necessarily indicate that special handling is required from the node. Some extension headers contain information relevant only to the destination node, and can be completely ignored by all nodes en-route to the destination. In fact, only hop-by-hop and router extension headers are relevant to all nodes and the latter is only applicable when the arriving packet is destined for the node. Fortunately, RFC2460 specifies that hop-by-hop extension headers be the first extension header after the IPv6 header. Thus a node can quickly determine if special handling for a packet is required simply by examining the destination address and the Next Header field of the IPv6 header.
An alternative to the previous approach is to simply limit the fields used in packet classification to those from the IP header such that the upper-layer header does not need to be examined. For MFC, this reduces the standard 5-tuple classification to a 3-tuple classification. This is not a very popular option as limiting the fields used in the MFC key for IPv6 means changing the way security of the node is controlled. Thus, a new set of rules must then be developed for IPv6 simply because it is sometimes inconvenient to read all the fields from the upper-layer header. Because of this, limiting the fields used in packet classification is not considered a competing solution.